Rollup of 11 pull requests

Successful merges:

 - #143717 (Add `Default` impls for `Pin`ned `Box`, `Rc`, `Arc`)
 - #144054 (Stabilize as_array_of_cells)
 - #144907 (fix: Reject async assoc fns of const traits/impls in ast_passes)
 - #144922 (Implement `#[derive(From)]`)
 - #144963 (Stabilize `core::iter::chain`)
 - #145436 (fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP`)
 - #145453 (Remove duplicated tracing span in bootstrap)
 - #145454 (Fix tracing debug representation of steps without arguments in bootstrap)
 - #145455 (Do not copy files in `copy_src_dirs` in dry run)
 - #145462 (Stabilize `const_exposed_provenance` feature)
 - #145466 (Enable new `[range-diff]` feature in triagebot)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #144922 - Kobzol:derive-from, r=nnethercote

Implement `#[derive(From)]`

Implements the `#[derive(From)]` feature ([tracking issue](#144889), [RFC](rust-lang/rfcs#3809)).

It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.

Implement `#[derive(From)]`

Implements the `#[derive(From)]` feature ([tracking issue](rust-lang#144889), [RFC](rust-lang/rfcs#3809)).

It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.

…=petrochenkov

Remove the `From` derive macro from prelude

The new `#[derive(From)]` functionality (implemented in rust-lang#144922) caused name resolution ambiguity issues (rust-lang#145524). The reproducer looks e.g. like this:

```rust
mod foo {
    pub use derive_more::From;
}

use foo::*;

#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```

It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require rust-lang#139493 to land.

I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.

Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.

Fixes: rust-lang#145524

r? ``@petrochenkov``

Rollup merge of #145563 - Kobzol:remove-from-from-prelude, r=petrochenkov

Remove the `From` derive macro from prelude

The new `#[derive(From)]` functionality (implemented in #144922) caused name resolution ambiguity issues (#145524). The reproducer looks e.g. like this:

```rust
mod foo {
    pub use derive_more::From;
}

use foo::*;

#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```

It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require #139493 to land.

I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.

Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.

Fixes: #145524

r? ``@petrochenkov``

…=petrochenkov

Remove the `From` derive macro from prelude

The new `#[derive(From)]` functionality (implemented in rust-lang#144922) caused name resolution ambiguity issues (rust-lang#145524). The reproducer looks e.g. like this:

```rust
mod foo {
    pub use derive_more::From;
}

use foo::*;

#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```

It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require rust-lang#139493 to land.

I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.

Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.

Fixes: rust-lang#145524

r? ``@petrochenkov``

This fixes an error from nightly. The trouble is that with nightly,
there's a now a [derive macro for From][issue].  That doesn't cause
a conflict when we `use derive_more::From`, but it _does_
cause a conflict when we import `derive_more::From` via
`use internal_prelude::*`.

So as a solution, we just import `derive_more::From` explicitly.

Closes #2124

[issue]: rust-lang/rust#144922

…nkov

Remove the `From` derive macro from prelude

The new `#[derive(From)]` functionality (implemented in rust-lang/rust#144922) caused name resolution ambiguity issues (rust-lang/rust#145524). The reproducer looks e.g. like this:

```rust
mod foo {
    pub use derive_more::From;
}

use foo::*;

#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```

It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require rust-lang/rust#139493 to land.

I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.

Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.

Fixes: rust-lang/rust#145524

r? ``@petrochenkov``